The so-called “Generic Bootstrapping Architecture” (GBA) is a technology standardized in the Third Generation Partnership Project (3GPP), that enables a client in a communications network to establish a shared secret key, e.g. denoted “Ks_NAF”, with a Network Application Function (NAF) located in a web server connected to the network.
A typical usage of GBA is for client authentication. As many currently existing applications are web based, i.e. available on the public Internet or an intranet, client authentication is particularly interesting when performed from a browser used by the client. A typical scenario is that the client is a communication terminal equipped with a browser operated by a user. To allow GBA to be used together with Hyper Text Mark up Language (HTML) form based authentication—being a widely used authentication method on Internet—it has been proposed to add a JavaScript Application Program Interface (API) at the client for GBA in web based applications. The JavaScript API is then executed by the client's browser and can be regarded as a part thereof.
The JavaScript API may be used at the client according to the following actions 1:1-1:4:    Action 1:1. The browser at the client downloads a login page from a web server over “HTTPS”, the latter referring to Hyper Text Transfer Protocol (HTTP) over Transport Layer Security (TLS) or Secure Socket Layer (SSL). The login page is a web page that contains an “HTML Form” with fields for “username” and “password”.    Action 1:2. The downloaded web page also contains a piece of JavaScript, hereafter called “script” for short. The script obtains a parameter called “Bootstrapping Transaction Identity, B-TID” identifying the client. The script further obtains a shared secret key denoted “Ks_NAF”, by calling the GBA JavaScript API provided by the client:    (B-TID, Ks_NAF)=window.documents.getGBAKey( );    The B-TID acts as a form of alias for an IMSI (International Mobile Subscriber Identity) of the client and the Ks_NAF is associated with the web server and possibly other web servers as well using the same NAF. The Ks_NAF is thus a key shared with the web server, which is used in    Action 1:4 below. In the present Action 1:2, the JavaScript API returns Ks_NAF and B-TID to the script.    Action 1:3. The script populates the HTML Form with the obtained B-TID as the username and the obtained Ks_NAF as the password. The resulting HTML Form is then submitted from the client to the web server.    Action 1:4. The web server, i.e. the NAF, authenticates the client by validating the username and password. In more detail, the NAF retrieves the Ks_NAF used by the client from a Bootstrapping Server Function (BSF) associated with the client, by presenting the B-TID received from the client in Action 1:2 to the BSF. The BSF derives the Ks_NAF, from a key shared with the client referred to as the “master key, Ks”. This is thus the same secret key the client obtained in Action 1:2. The Ks_NAF is unique for each NAF and Ks.
However, the existing proposal to add a JavaScript API at the client is vulnerable to so-called “script injection attacks”. By finding ways of injecting malicious scripts into web pages, an attacker can gain elevated access privileges, or access, to sensitive page-content, cookies, and a variety of other information that may be maintained by the browser on behalf of the user. Whether a web page is susceptible to script injection in this way or not depends on its contents and the security mitigations implemented by the web server's owner, effectively being the page owner.
A problem with the proposal above has been identified in that the shared secret key Ks_NAF returned by the JavaScript API at the client in the procedure above has a very wide scope of usage. A key “stolen” by an attacker through script injection may remain valid and useful across an entire Domain Name System (DNS) type of domain, e.g. “naf.com”, and across different HTTP sessions with the server(s) using that NAF.
To illustrate this, an example will be considered with a host “naf.com” which is a web server having two accessible web-pages denoted “login.html” and “vulnerable.html”. The first page login.html has been meticulously and thoroughly coded and is in itself invulnerable to any type of attack. The second page vulnerable.html, on the other hand, contains a subtle flaw which effectively makes it susceptible to code injection. Realizing this, an attacker injects the following “malicious” script into the second web page:    <SCRIPT type=“text/javascript”>    (B-TID, Ks_NAF)=window.document.getGBAKey( );    . . . upload (B-TID, Ks_NAF) to attacker . . .    </SCRIPT>
The next user who visits the second web page naf.com/vulnerable.html and obtains the shared key according to the above procedure, will unknowingly upload his obtained key to the attacker by means of the above malicious script injected into the second web page. As a result, the attacker can in turn use that key to login at naf.com/login.html and be properly authenticated.
In another example, a downloaded vulnerable HTML document is rendered in a client browser. The document contains a command that instructs the browser to download and execute a third party script which may be an advertisement, a visitor counter or other apparently harmless application. The third party script however also contains a line which retrieves the Ks_NAF and B-TID of the client, which is accordingly done when the script is executed. The script also adds a link to the rendered web page which is a command to upload the Ks_NAF and B-TID to the “evil” third party. Believing that the link is useful but harmless, the user clicks on the link and the upload is then executed. Thereby, the third party obtains the Ks_NAF and B-TID of the client for later illicit usage.
It is thus a problem that an attacker can get hold of sensitive information of a particular client such as a shared secret key, and use that information for fake authentication and verification in forthcoming sessions with web servers where that information is valid.